Este servicio es exclusivo para el servidor del distrito trece ya que el resto de participantes con una base de datos contendrán una base de mariadb
apt install postgresql -y
Editamos el archivo de configuración /etc/postgresql/15/main/postgresql.conf modificando la linea de listen_addresses por la actual de la imagen

También editamos el archivo /etc/postgresql/15/main/pg_hba.conf la línea de configuración de las conexiones por IPV4 por la de la imagen

Reiniciamos el servicio y comprobamos que esté funcionando correctamente

Mariadb

Instalamos el paquete de mariadb-server utilizando apt install mariadb-server -y y editamos el archivo de configuración de /etc/mysql/mariadb.conf.d/50-server.cnf

Después de esto reiniciamos el servicio

Apache2

Vamos a instalar el parquete apache2 utilizando apt install apache2 -y y vamos a configurar un nuevo virtualhost para reconocer a cada participante, para ello comenzamos con lo siguiente:

creamos la siguiente estructura /var/www/(nombre_participante)/index.html
Le damos los siguientes permisos con el usuario root:
- chmod 644 /var/www/(nombre_participante)/index.html
- chmod 755 /var/www/(nombre_participante)
Editamos el index.html y añadimos alguna información descriptiva del participante
creamos un archivo en /etc/apache2/sites-avaiable/(nombre_participante).conf
aplicamos una configuración básica como la de la imagen
Creamos un soft link de este archivo utilizando el comando ln /etc/apache2/sites-available/peeta.conf /etc/apache2/sites-enable/
Eliminamos el link de la web por defecto de apache para que al buscar por la ip aparezca la web de peeta

isc-dhcp-server

Para instalar el servicio de dhcp utilizamos el siguiente comando apt install isc-dhcp-server -y. Este servicio lo configuraremos cuando nos sea necesario ahora mismo lo mantendremos deshabilitado

CLIENTES

En este escenario nos descargamos el cliente de postgres y de mariadb para ello apt install mariadb-client -y && apt install postgresql-client -y

Con el comando curl podemos obtener el código html de los servidores apaches y el cliente ssh ya viene por defecto en las máquinas debian

ASIGNACIÓN DE IP

Marvel	10.0.1.2 despues DHCP
Glimmer	10.0.1.3 despues DHCP
Cato	10.0.2.2
Clover	10.0.2.3
Thresh	10.0.11.2
Rue	10.0.11.3
Peeta	10.0.12.2
Katniss	10.0.12.3
Servidor distrito 13	10.0.13.2
R1 ens4	10.0.1.1
R1 ens5	173.23.0.1
R1 ens6	193.168.1.2
R2 ens4	10.0.11.1
R2 ens5	173.23.0.2
R2 ens6	173.24.0.1
R2 ens7	193.168.11.2
R3 ens4	10.0.2.1
R3 ens5	173.25.0.1
R3 ens6	193.168.2.2
R4 ens4	10.0.12.1
R4 ens5	173.25.0.2
R4 ens6	173.24.0.2
R4 ens7	193.168.12.2
R5 ens4	10.0.13.1
R5 ens5	193.168.1.1
R5 ens6	193.168.11.1
R5 ens7	193.168.2.1
R5 ens8	193.168.12.1

ENRUTAMIENTO

Primero debemos de habilitar el bit de forwarding preferiblemente de forma persistente editando el archivo /etc/sysctl.cof descomentando la linea net.ipv4.ip_forward=1

Para las rutas añadiremos en los routers R1,R2,R3,R4 únicamente la salida por defecto el resto de rutas necesarias se añaden solas debido a que están directamente conectadas a los routers, por lo que R5 no necesitará cambios en sus rutas

DNAT Y SNAT

SNAT

Vamos a comenzar con las reglas de SNAT, poniendo como ejemplo R1 y después aplicando las mismas reglas adaptadas en los demás routes.

Crearemos un archivo para almacenar las reglas de iptables, utilizando iptables-save --file /etc/rules_iptables generamos directamente una plantilla para ir añadiendo los diferentes tipos de reglas
Para realizar SNAT en R1 hay que crear una regla por cada interfaz de salida disponibles, en este caso 2 donde indicamos lo siguiente

-A POSTROUTING -s 10.0.1.0/24 -o ens5 -j SNAT --to-source 173.23.0.1
-A POSTROUTING -s 10.0.1.0/24 -o ens6 -j SNAT --to-source 193.168.1.2

Con estas reglas indicamos que el trafico con origen en la red privada y con salida por las interfaces ens5 y ens6 tengan como IP de origen las IPs 173.23.0.1 y 193.168.1.2

Para comprobar que se realiza correctamente la traducción podemos usar una captura de wireshark

DNAT

Para configurar el DNAT debemos de utilizar 1 regla para cada servicio de cada máquina y por cada interfaz, por ejemplo para conectarnos por ssh a marvel

Finalmente estos serían los archivos finales de reglas iptables únicamente con la configuración de SNAT y DNAT.

COMPROBACIONES

DISTRITO 1

DISTRITO 11

DISTRITO 2

DISTRITO 12

POLÍTICA POR DEFECTO

Para añadir la politica por defecto DROP en iptables podemos utilizar el comando iptables -P input/output/forward DROP o simplemente editando el archivo que creamos de las reglas /etc/rules_iptables

Después de eso volvemos a cargar las reglas en memoria para aplicar los cambios del archivo

CONSERVAR ACCESO SSH ROUTER

Para permitir el acceso por ssh al router, primero que tenemos que hacer es modificar el número de puerto del servicio ssh del router para evitar confusiones en el trafico respecto a los de el servidor de la red interna, para ello modificamos el archivo /etc/ssh/sshd_config donde descomentamos la línea del puerto y ponemos uno al azar, que este libre

Reiniciamos el servicio con systemctl restart sshd
Indicamos al cortafuegos que permita el acceso de entrada y salida cuando se tenga en puerto de destino y puerto de origen el 5333, si queremos que solo se permite para las redes privadas hay que indicar -s para las ips de origen -d para indicar las ips de destino

Esa regla funciona en todos los routers menos en R5 ya que hay que añadir el parámetro -s IP_PUBLICA o -d IP_PUBLICA en cada regla y por interfaz, para evitar que se acepte el trafico con ese puerto pero no vaya como destino él por ejemplo entre Distrito 11 y Distrito 2

Este proceso de cambio de puerto es necesario en este caso debido a que si no lo cambiamos el router intenta realizar los procesos de NAT, en caso de que solo nos podamos conectar desde la red interna únicamente esto no sería necesario.
También hay que tener en cuenta que estas reglas no permite que el router sea cliente ssh

IPTABLES PERSISTENTE

Para tener las reglas persistentes, podemos crear un script que ejecute el comando iptables-restore < /etc/rules_iptables y después crear un servicio de una única ejecución a la hora de iniciar la máquina

Debemos de tener en cuenta que el servicio debe de estar habilitado systemctl enable iptables.service e iniciado systemctl start iptables.service

LOS CORTAFUEGOS HAN INTERRUMPIDO TODAS LAS COMUNICACIONES

Para comprobar que se han cortado las comunicaciones simplemente podemos realizar ping a alguna interfaz pública de los routers desde algún equipo de la red local

R1-R2,R3,R4,R5 {#r1-r2,r3,r4,r5}

R2-R3,R4,R5 {#r2-r3,r4,r5}

R3-R3,R4 {#r3-r3,r4}

R4 Y R5

D) CONFIGURA LAS SIGUIENTES REGLAS DE CORTAFUEGOS {#d)-configura-las-siguientes-reglas-de-cortafuegos}

Los Indigentes pueden acceder al servidor de base de datos de los pobres

Para permitir esta conexión hay que añadir 2 pares de reglas forward, 1 par en cada router.

POBRES
- -A FORWARD -s 173.24.0.2 -p tcp -m tcp --dport 3306 -j ACCEPT
- -A FORWARD -d 173.24.0.2 -p tcp -m tcp --sport 3306 -j ACCEPT

Con la primera regla le indicamos al router de los pobres que permita el tráfico que tenga como origen la ip pública de los indigentes y como puerto de destino el del servidor de mariadb (“Las peticiones”)
Con la segunda regla permitimos el tráfico con origen en el servidor y destino la IP pública del router (“Las respuestas”)

INDIGENTES
- -A FORWARD -d 173.24.0.1 -p tcp -m tcp --dport 3306 -j ACCEPT
- -A FORWARD -s 173.24.0.1 -p tcp -m tcp --sport 3306 -j ACCEPT

En el caso de las reglas de los indigentes son similares pero aplicadas desde el punto de vista de su router y no del de los pobres

Podemos ver que la conexión se realiza exitosamente

Desde wireshark también podemos comprobar el trafico

Si intentamos la conexión a la inversa podemos ver que los cortafuegos no lo permiten, de manera que no hay tráfico en wireshark

Los indigentes y los pobres pueden acceder al servidor ssh alojado en el distrito 13

R2
- -A FORWARD -d 193.168.11.1 -p tcp -m tcp --dport 22 -j ACCEPT
- -A FORWARD -s 193.168.11.1 -p tcp -m tcp --sport 22 -j ACCEPT
R4
- -A FORWARD -d 193.168.12.1 -p tcp -m tcp --dport 22 -j ACCEPT
- -A FORWARD -s 193.168.12.1 -p tcp -m tcp --sport 22 -j ACCEPT
R5
- -A FORWARD -s 193.168.11.2 -p tcp -m tcp --dport 22 -j ACCEPT
- -A FORWARD -s 10.0.13.2 -p tcp -m tcp --sport 22 -j ACCEPT
- -A FORWARD -s 193.168.12.2 -p tcp -m tcp --dport 22 -j ACCEPT
- -A FORWARD -s 10.0.13.2 -p tcp -m tcp --sport 22 -j ACCEPT

Clove puede acceder a los servidores de los superpijos menos al ssh

R3
- -A FORWARD -s 10.0.2.3 -p tcp -m tcp --dport 80 -j ACCEPT
- -A FORWARD -s 193.168.1.2 -p tcp -m tcp --sport 80 -j ACCEPT
- -A FORWARD -s 10.0.2.3 -p tcp -m tcp --dport 3306 -j ACCEPT
- -A FORWARD -s 193.168.1.2 -p tcp -m tcp --sport 3306 -j ACCEPT
R5
- #PERMITIMOS TRAFICO DE ORIGEN DISTRITO 2 A 1 HTTP MARIADB
- -A FORWARD -s 193.168.2.2 -d 193.168.1.2 -p tcp -m tcp --dport 80 -j ACCEPT
- -A FORWARD -s 193.168.2.2 -d 193.168.1.2 -p tcp -m tcp --dport 3306 -j ACCEPT
- #PERMITIMOS EL TRAFICO DE ORIGEN DE DISTRITO 1 A 2 HTTP MARIADB
- -A FORWARD -s 193.168.1.2 -d 193.168.2.2 -p tcp -m tcp --sport 80 -j ACCEPT
R1
- #TRAFICO CON ORIGEN DISTRITO 2 HTTP Y MARIADB
- -A FORWARD -s 193.168.2.2 -p tcp -m tcp --dport 80 -j ACCEPT
- -A FORWARD -s 193.168.2.2 -p tcp -m tcp --dport 3306 -j ACCEPT
- #TRÁFICO DE ORIGEN RED PRIVADA HTTP Y MARIADB
- -A FORWARD -s 10.0.1.0/24 -p tcp -m tcp --sport 80 -j ACCEPT
- -A FORWARD -s 10.0.1.0/24 -p tcp -m tcp --sport 3306 -j ACCEPT

Marvel permite que Peeta acceda a su servidor Web con peticiones en el 8085

Debemos de cambiar el DNAT que se realiza en R1 y permitir el tráfico de origen y destino del distrito 12

R1
- -A PREROUTING -d 193.168.1.2/32 -p tcp -m tcp --dport 8085 -j DNAT --to-destination 10.0.1.2:80

Con esa modificación las peticiones que lleguen por la interfaz de la ip publica 193.168.1.2 con puerto de destino 8085 seran reenviadas a la maquina 10.0.1.2 al puerto 80

#PERMITIR TRAFICO CON ORIGEN DISTRITIO 12 HTTP 8085
- -A FORWARD -s 193.168.12.2 -p tcp -m tcp --dport 80 -j ACCEPT
- -A FORWARD -s 10.0.1.2 -d 193.168.12.2 -p tcp -m tcp --sport 80 -j ACCEPT

R4
- #PERMITIR QUE PEETA HAGA PETICIONES 8085 A MARVEL
- -A FORWARD -s 10.0.12.2 -p tcp -m tcp --dport 8085 -j ACCEPT
- -A FORWARD -s 193.168.1.2 -p tcp -m tcp --sport 8085 -j ACCEPT

R5
- #PERMITIMOS EL TRAFICO DE DISTRITO 12 A 1 HTTP 8085
- -A FORWARD -s 193.168.12.2 -d 193.168.1.2 -p tcp -m tcp --dport 8085 -j ACCEPT
- -A FORWARD -s 193.168.1.2 -d 193.168.12.2 -p tcp -m tcp --sport 8085 -j ACCEPT

*NAT TAMBIÉN RESTAURA LOS PUERTO ORIGINALES DE LAS PETICIONES *

Los pijos han conseguido acceder al servidor postgres del distrito 13

R3
- #TRAFICO POSTGRES DISTRITO 13
- -A FORWARD -s 10.0.2.0/24 -p tcp -m tcp --dport 5432 -j ACCEPT
- -A FORWARD -s 193.168.2.1 -p tcp -m tcp --sport 5432 -j ACCEPT
R5
- #PERMITIMOS TRAFICO POSTGRES DESDE DISTRITO 2
- -A FORWARD -s 193.168.2.2 -p tcp -m tcp --dport 5432 -j ACCEPT
- -A FORWARD -s 10.0.13.2 -p tcp -m tcp --sport 5432 -j ACCEPT

Katniss ha conseguido reglas que le permiten infiltrarse a todos los servidores ssh

Debemos permitir desde su router únicamente el acceso ssh a katniss.
También hay que modificar reglas anteriores ya creadas que permiten el acceso por ssh tanto de Katniss como de Peeta

R1
- -A FORWARD -s 193.168.12.2 -p tcp -m tcp --dport 22 -j ACCEPT
- -A FORWARD -d 193.168.12.2 -p tcp -m tcp --sport 22 -j ACCEPT

R2
- -A FORWARD -s 173.24.0.2/32 -p tcp -m tcp --dport 22 -j ACCEPT
- -A FORWARD -d 173.24.0.2/32 -p tcp -m tcp --sport 22 -j ACCEPT

R3
- -A FORWARD -s 173.25.0.2/32 -p tcp -m tcp --dport 22 -j ACCEPT
- -A FORWARD -d 173.25.0.2/23 -p tcp -m tcp --sport 22 -j ACCEPT

R5
- -A FORWARD -s 193.168.12.2 -p tcp -m tcp --dport 22 -j ACCEPT
- -A FORWARD -d 193.168.12.2 -p tcp -m tcp --sport 22 -j ACCEPT

R4
- -A FORWARD -s 10.0.12.3 -p tcp -m tcp --dport 22 -j ACCEPT
- -A FORWARD -p tcp -m tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

Comprobación

Katniss-Distrito 11

Katniss-Distrito 2

Katniss-Distrito 13

Katniss-Distrito 1

Peeta

Los superpijos han planeado realizar un ataque DDOS por escaneo de puertos

El escaneo muestra 2 servicios de los indicados los cuales el servicio ssh está filtrado por el cortafuegos y el postgresql nos indica el estado abierto y la versión

Primero vamos a utilizar hping3 con los siguientes parámetros para ver un poco de información
hping3 -S -p 5432 -V --fast 193.168.1.1

Vamos a utilizar hping3 para enviar paquetes SYN al router
hping3 -S(bandera SYN) -p(puerto) 5432 --flood(lo más rápido posible) 193.168.1.1 este comando tambien cuenta con la opción --rand-source(dirección ip aleatorio) pero para este caso no nos sirve ya que el cortafuegos de R5 descarta todos los paquetes con IPs diferentes

La solución es modificar la regla en R5 para indicarle un máximo de 3 conexiones TCP simultaneas para ello

#PERMITIMOS A DISTRITO 1 UN MÁXIMO DE 3 CONEXIONES SIMULTANEAS AL PUERTO 5432
-A FORWARD -s 193.168.1.2 -p tcp -m tcp --dport 5432 -m connlimit --connlimit-above 3 -j ACCEPT
-A FORWARD -d 193.168.1.2 -p tcp -m tcp --dport 5432 -m connlimit --connlimit-above 3 -j ACCEPT

Ponemos los contadores a 0 y probaremos de nuevo el ataque

Vemos en la parte superior que ha rechazado los paquetes

CONFIGURA UN SERVIDOR DHCP

Para configurar un servidor dhcp utilizar un script propio subido a mi github: https://github.com/M4nue/config_dhcp/blob/main/dhcp.sh

bash dhcp.sh -f 10.0.1.2 -l 10.0.1.5 -n 255.255.255.0 -S 10.0.1.0 -r 10.0.1.1 -b 10.0.1.255

Para ver la configuración actual activa en el archivo de configuración de dhcp utilizaremos la opción -s de nuestro script

Ahora configuraremos el cortafuegos para que permita el tráfico de los paquetes DHCP, para ello utilizaremos reglas INPUT y OUTPUT

-A OUTPUT -p udp -m udp --dport 67 --sport 68 -j ACCEPT
-A OUTPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT

Marvel y Glimmer ya están configurados para obtener ip del servidor y no estatica por lo que al iniciarlos obtendrán una IP aleatoria

Desde wireshark podemos ver que se han capturados los paquetes de DHCP

También podemos añadir otra maquina a la red para comprobar que se asigna otra configuración TCP/IP

BIBLIOGRAFÍA

https://www.fortinet.com/lat/resources/cyberglossary/what-is-port-scan
https://www.redeszone.net/tutoriales/configuracion-puertos/puertos-abiertos-atacar-que-pueden-hacer/
https://www.cloudflare.com/es-es/learning/ddos/ddos-attack-tools/how-to-ddos/
https://www.geeksforgeeks.org/slowloris-ddos-attack-tool-in-kali-linux/
https://www.redeszone.net/tutoriales/seguridad/hping3-manipular-paquetes-tcp-ip-ataques/
https://www.baeldung.com/linux/iptables-limit-connections

This post is licensed under CC BY 4.0 by the author.